… "pending"

POST /v1/chat/tasks returned ``status="pending"`` in the response
body even though ``begin_turn`` had already atomically claimed the
row as RUNNING inside the same handler before the response was
sent. An SDK client doing POST followed by an immediate GET on the
same task would see two contradictory status values from
back-to-back calls (``pending`` then ``running``).

Read ``task.status.value`` after ``begin_turn`` returns instead --
``begin_turn`` refreshes the in-memory ``task`` after committing
the atomic claim, so the post-handler view reflects the row's real
state. ``AppendMessageResponse`` already followed this contract;
the create path now matches it.

Schema docstrings for CreateTaskResponse and AppendMessageResponse
updated to describe the post-claim ``running`` semantics; the
``test_create_task_happy_path`` assertion was checking for the old
``pending`` value and has been updated.

No behavior change in the orchestrator or scheduler -- this is a
response-payload correctness fix only. Twenty-eight v1 task tests
pass; pre-commit (ruff / mypy / isort / codespell) green.

…nse status read

Follow-up to the CreateTaskResponse status fix in the previous
commit. Two consistency cleanups within the same handler module:

1. ``create_chat_task`` function docstring still described the
   return value as ``status='pending'`` -- inconsistent with the
   schema docstring and the implementation that the previous commit
   already moved to ``task.status.value`` (i.e. 'running'). Updated
   the Returns section to match.

2. ``append_message_to_task`` returned ``status="running"`` hard-
   coded while ``create_chat_task`` reads ``task.status.value``.
   Unified both endpoints on the same pattern -- reading from the
   refreshed in-memory row is defensive (any future ``begin_turn``
   status-machine change is picked up automatically) and removes
   the asymmetry where one endpoint reflected the DB and the other
   asserted a fixed string.

No behavior change for the current contract -- the previous commit
already returned 'running' from CREATE; this commit makes APPEND
share the same expression form and fixes the docstring drift.
Twenty-eight v1 task tests pass; pre-commit green.

…lure

``execute_task_background`` previously logged and broadcast the
exception text on failure but never wrote it to ``task.error_message``.
The row's status stayed RUNNING, and ``finish_turn``'s
RUNNING-fallback branch then unconditionally set
``error_message`` to a generic placeholder ("Task execution failed
without status update; see /steps."), forcing SDK and web clients
to fetch ``/steps`` to discover what actually went wrong.

The fix writes the real exception text to ``task.error_message`` and
flips ``status`` to ``FAILED`` in the exception handler, using a
fresh session because the original may be in a failed-transaction
state. ``finish_turn``'s FAILED branch then only fills in a
placeholder when ``error_message`` is empty, so the real message is
preserved through to the final row state.

Same family of fix as the ``status="pending"`` correction above:
make the persisted task row reflect the real outcome rather than a
generic placeholder. Affects both SDK consumers (GET /v1/chat/tasks/
{id}) and web/WebSocket consumers reading the same row.

Twenty-eight v1 task tests pass; pre-commit (ruff / mypy / isort /
codespell) green.

…site

execute_task_background's outer except spans post-terminal steps
(assistant-message persistence and the completion/paused broadcasts)
that run after the task status was already committed COMPLETED. The
recently added FAILED-persistence wrote the row unconditionally, so a
failure in one of those best-effort steps -- e.g. the completion
broadcast losing its websocket -- rewrote an already-completed task as
FAILED and stored the broadcast error in error_message.

Branch the handler on the task's current status instead. Only a task
still RUNNING is a genuine execution failure: record the real exception
text, flip to FAILED, and emit task_error. A task already in a terminal
state tripped here in a best-effort post-completion step, so observe it
without touching the row or emitting a contradictory task_error;
finish_turn still reconciles the terminal fields afterward.

The success path committed COMPLETED/FAILED before persisting the
assistant message, which is a separate durable write. If that write
failed, the row was left COMPLETED with no message and no error_message
-- the status-gated failure handler treated it as a best-effort
post-completion step and left it untouched.

Leave the terminal status pending and let persist_assistant_message's
commit land it atomically with the message. A failure in that durable
write now leaves the status RUNNING, so the outer handler surfaces a
real task failure instead of a contradictory empty COMPLETED row. Only
notification broadcasts remain best-effort.